数据中台建设方法论、技术体系、组织架构

点击上方关注, 星标一起成长

1

数据中台建设的方法论

数据中台建设的方法论就是我们的指导思想，主要分为2大块：

（1）数据统一管理

（2）服务化

（一）数据统一管理

数据统一管理有如下方法/要点：

1、按主题域管理

 数据按照业务主题域管理，比如用户域、订单域、物流域等等。

2、数据完备

数据中台中的数据尽可能完备，从业务过程⻆度看覆盖范围是完善的（各主题域要覆盖所有业务，提前梳理和熟悉整体的业务），从分层的⻆度来看，尽量避免跨层构建，即避免明细层数据和轻度汇总层数据缺失

ODS层 原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。 

DWD层 明细数据层 结构和粒度与ods层保持一致，对ods层数据进行清洗(去除空值，脏数据，超过极限范围的数据)，也有公司叫dwi。

DWS层（轻度汇总层，按业务要求的最细粒度汇总） 服务数据层 以dwd为基础，进行轻度汇总。一般聚集到以用户当日，设备当日，商家当日，商品当日等等的粒度。在这层通常会有以某一个维度为线索，组成跨主题的宽表。

比如一个用户的当日的签到数、收藏数、评论数、抽奖数、订阅数、点赞数、浏览商品数、添加购物车数、下单数、支付数、退款数、点击广告数组成的多列表。ADS层(数据集市层) 数据应用层， 也有公司或书把这层成为app层、 dal层、 dm层，叫法繁多。面向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。

统计结果最终同步到RDS以供BI或应用系统查询使用。

我们这里所说的数据集市指的是ሀ义的数据集市，也就是加工好的数据可以拿出来了（好比摆在”集市“上卖）。

广义的数据集市可以理解为部门级别的数仓，正好跟数据中台是反着来的。

3、制定并推行命名规范

好的命名规范应该根据表名就知道所属的主题域、分层、表类型(快照表、增量表)

4、提高数据模型复用性

模型设计尽量考虑复用性，不要一个表的数据被翻来覆去重复加工，而是统一成一个模型供大家复用。

5、统一指标口径

指标一致性：不同的系统出现相同的指标名

（二）服务化

如果没有数据服务化，数据接入和访问不是一个标准化的流程，则会导致一系列问题。要把整个数据开发的流水线通过系统的方式去打通。

2

数据中台技术体系

数据中台的落地是需要一套技术体系来支撑的，数据中台架构就是这套体系的具体实现：

3

数据中台组织架构

数据中台是“一把手”工程，需要从上到下进行,企业要想建设数据中台，至少需要 CIO 或者CTO层面推动，最好是最大boss推动。中台是战略层面的事情而不是战术层面，自下向上推动动乎没有可能，比如涉及标准统一等。

具体来说，数据中台是一个集数据采集、融合、治理、组织管理、智能分析为一体，将数据以服务方式提供给前台应用，以提升业务运行效率、持续促进业务创新为目标的整体平台。从下而上往往只能看到其中一个点，难免会以偏概全，毕竟大部分员工很难站在一定的高度去做一个”看十年、做一年“的规划，特别是当一件事和眼前的 KPI 难以达成平衡时，中台的工作会受到各个方面的挑战。因此，高层的坚定支持是中台战略的第一必要条件。

当企业高层决定建设数据中台后，下一步就要考虑中台团队的人员组成以及整个团队在组织架构中的位置。对于是否要进行大的组织架构调整，首先要看企业的业务复杂程度。类似阿里巴巴、京东等大厂需要通过组织架构调整来保障战略顺利推进，但规模相对较小的企业可能没有必要进行组织架构调整；其次，取决于企业决策者对数据中台

战略的态度，是否将其放到整个公司的战略高度，类似阿里巴巴、京东等大厂已经将数据中台作为重要战略，陆续进行了组织架构变更。

典型的数据中台组织架构如下：

组织架构是基础，各个团队分散到各个部门，数据中台基本不会建立起来的。一般典型的做法是，整个数据中台团队由原来的大数据团队整编过来，直接汇报给CTO/CIO，也可能会报给老板，整个部门一般会有一个大数据总监来负责。

（1）数据产品团队：负责数据产品、数据中台的整体规划，制定数据相关规范监督落地

（2）数据平台团队：平台工具的研发，整体架构的演进，一般会高配比较厉害的架构师

（3）数据开发团队：日常数据研发、数据集成、计算、治理等等

（4）数据应⽤团队：数据应用产品研发，一般是面向业务过程、行业的、通用的数据应用 

欢迎点赞 + 收藏 + 在看  三连 

完

数据研发，欢迎大家关注！